fix(test-plans): use self-contained Maven fixture for resolve-unknown-type plan#1617
Merged
Conversation
…-type plan The plan previously pointed at redhat-developer/vscode-java's salut Maven fixture, which configures maven-compiler-plugin with <source>1.7</source>/<target>1.7</target>. On the CI runners (which install only JDK 21) this puts the workspace in a state where JDT reports compliance warnings on the pom but skips full semantic analysis on the Java source -- the inserted `Gson gson;` field never produces a `Gson cannot be resolved to a type` diagnostic, so navigateToError can never find the error and applyCodeAction `Resolve unknown type` is unreachable. Older versions of @vscjava/vscode-autotest masked this failure mode by silently pressing Enter on whatever the first Code Action happened to be; once that fallback was removed upstream the plan started reliably failing in scheduled runs (e.g. actions/runs/25419116469). Add a minimal self-owned Maven fixture under test-fixtures/maven-resolve-type that explicitly targets JDK 11 (<release>11</release>), matching the JDK installed by the workflow. Locally this brings navigateToError from a 30s timeout to ~8s and the full plan to 6/6 passing. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
wenytang-ms
requested review from
chagong,
jdneo and
testforstephen
as code owners
chagong
approved these changes
May 7, 2026
Copilot AI
pushed a commit
that referenced
this pull request
May 11, 2026
…-type plan (#1617) The plan previously pointed at redhat-developer/vscode-java's salut Maven fixture, which configures maven-compiler-plugin with <source>1.7</source>/<target>1.7</target>. On the CI runners (which install only JDK 21) this puts the workspace in a state where JDT reports compliance warnings on the pom but skips full semantic analysis on the Java source -- the inserted `Gson gson;` field never produces a `Gson cannot be resolved to a type` diagnostic, so navigateToError can never find the error and applyCodeAction `Resolve unknown type` is unreachable. Older versions of @vscjava/vscode-autotest masked this failure mode by silently pressing Enter on whatever the first Code Action happened to be; once that fallback was removed upstream the plan started reliably failing in scheduled runs (e.g. actions/runs/25419116469). Add a minimal self-owned Maven fixture under test-fixtures/maven-resolve-type that explicitly targets JDK 11 (<release>11</release>), matching the JDK installed by the workflow. Locally this brings navigateToError from a 30s timeout to ~8s and the full plan to 6/6 passing. Co-authored-by: copilot <copilot@local> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: chagong <831821+chagong@users.noreply.github.com>
chagong
added a commit
that referenced
this pull request
May 11, 2026
…9 + @vscode-elements/elements (#1616) * Migrate webviews from React 16 + react-bootstrap to React 19 + @vscode-elements/elements - Upgrade React 16.14.0 to React 19.x with react-jsx transform - Replace deprecated @vscode/webview-ui-toolkit with @vscode-elements/elements (Lit-based) - Replace react-bootstrap components with native HTML + custom SCSS - Add custom Bootstrap-equivalent utility classes in vscode.scss - Add TypeScript declarations for vscode-elements web components - Migrate all webview entry points to React 19 createRoot API - Convert class components to functional components - Update webpack config for React 19 compatibility - Fix tas-client version compatibility (override to ~0.2.33) * fix: derive AWT action at render time without mutating shared groups array * fix: add fallback for --design-unit CSS variable @vscode-elements/elements does not define --design-unit (was provided by @vscode/webview-ui-toolkit). Add fallback value of 4 so spacing utilities (mr-*, ml-*, pt-*, etc.) resolve correctly. * fix(test-plans): use self-contained Maven fixture for resolve-unknown-type plan (#1617) The plan previously pointed at redhat-developer/vscode-java's salut Maven fixture, which configures maven-compiler-plugin with <source>1.7</source>/<target>1.7</target>. On the CI runners (which install only JDK 21) this puts the workspace in a state where JDT reports compliance warnings on the pom but skips full semantic analysis on the Java source -- the inserted `Gson gson;` field never produces a `Gson cannot be resolved to a type` diagnostic, so navigateToError can never find the error and applyCodeAction `Resolve unknown type` is unreachable. Older versions of @vscjava/vscode-autotest masked this failure mode by silently pressing Enter on whatever the first Code Action happened to be; once that fallback was removed upstream the plan started reliably failing in scheduled runs (e.g. actions/runs/25419116469). Add a minimal self-owned Maven fixture under test-fixtures/maven-resolve-type that explicitly targets JDK 11 (<release>11</release>), matching the JDK installed by the workflow. Locally this brings navigateToError from a 30s timeout to ~8s and the full plan to 6/6 passing. Co-authored-by: copilot <copilot@local> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: chagong <831821+chagong@users.noreply.github.com> * ci: add autotest cases (#1619) Co-authored-by: chagong <831821+chagong@users.noreply.github.com> --------- Co-authored-by: wenyt <75360946+wenytang-ms@users.noreply.github.com> Co-authored-by: copilot <copilot@local> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: chagong <831821+chagong@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & Why
The
java-maven-resolve-typeE2E plan has been failing in scheduled runs (e.g. actions/runs/25419116469). Investigation showed:redhat-developer/vscode-java'ssalutMaven project, which sets<source>1.7</source>/<target>1.7</target>.Java: Ready, but never publishes semantic diagnostics forFoo.java. SoGson gson;does not produce aGson cannot be resolved to a typeerror andnavigateToError/applyCodeAction "Resolve unknown type"cannot proceed.@vscjava/vscode-autotestmasked this with a silent-fallback inapplyCodeAction(Enter on whatever the first action happened to be). Once that fallback was removed upstream, the plan started consistently failing on[check-code-action] applyCodeAction "Resolve unknown type"withAvailable actions: Extract interface..., Source Actions....Verified locally: bumping the pom to
<release>11</release>makes JDT publish the unresolved-type diagnostic in ~8 s and the full plan goes from 4/6 → 6/6 passed.Change
Add a small, self-contained Maven fixture under
test-fixtures/maven-resolve-type/that targets JDK 11 explicitly, and re-point the test plan at it:test-fixtures/maven-resolve-type/pom.xml—maven-compiler-plugin 3.8.0,<release>11</release>, no extra deps.test-fixtures/maven-resolve-type/src/main/java/com/example/App.java— minimal class.test-fixtures/maven-resolve-type/README.md— explains why the fixture lives here and the JDK-compliance pitfall.test-plans/java-maven-resolve-type.yaml—workspacerepointed; opensApp.java; insertsGson gson;at line 4 (inside the class body); rest of the steps unchanged.Why a local fixture rather than reusing
salut-java11Owning the fixture in this repo decouples this plan from upstream
vscode-javatest-resource changes and removes the implicit ordering dependency ofgit clone vscode-javafinishing before this plan can run.Verification
Local run with
@vscjava/vscode-autotest(with the upcomingnavigateToErrorfix that fails fast instead of falling through to warnings):Problems panel screenshot confirms
Gson cannot be resolved to a type Java(16777218)is published onApp.java:4, which is the diagnostic code thevscode-mavenResolve unknown typeCode Action keys on.